home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / lang / c++-part1 / 9313 < prev    next >
Encoding:
Internet Message Format  |  1996-08-05  |  2.6 KB
  1. Path: anvil.ugrad.cs.ubc.ca!not-for-mail
  2. From: c2a192@ugrad.cs.ubc.ca (Kazimir Kylheku)
  3. Newsgroups: comp.lang.c++,comp.lang.c
  4. Subject: Re: Q: follow(expect,ifyes,ifno) buggy?
  5. Date: 28 Feb 1996 08:50:55 -0800
  6. Organization: Computer Science, University of B.C., Vancouver, B.C., Canada
  7. Message-ID: <4h215fINNmoi@anvil.ugrad.cs.ubc.ca>
  8. References: <4gv9a9$nfu@tuegate.tue.nl>
  9. NNTP-Posting-Host: anvil.ugrad.cs.ubc.ca
  10.  
  11. In article <4gv9a9$nfu@tuegate.tue.nl>,
  12. Pieter Kuppens <pwk@news.eb.ele.tue.nl> wrote:
  13. >In compiler construction (with C) the following function is often used:
  14. >
  15. >follow(expect,ifyes,ifno)
  16. >{
  17. >    int c = getchar();
  18. >    if (c==expect) return ifyes;
  19. >    ungetc(c,stdin);
  20. >    return ifno;
  21. >}
  22. >
  23. >I have my doubts on this function. If calls are nested:
  24. >(abbrev. LA (look ahead) instead of follow)
  25. >LA('/',LA('/',COMMENT_LINE,LA('*',COMMENT,DIV)))
  26. >may very well fail on the following:
  27. >nested call LA is evaluated in the function call, before another
  28. >function LA is completed. Look ahead at 1 position further can disturb
  29. >correct evaluation of this function.
  30.  
  31. Does the LA macro insert a proper "ifno" return value for each call?
  32. You are invoking the outermost LA with only one argument, but the second and
  33. innermost one with three arguments.
  34.  
  35. Please check your code for basic syntactic correctness before asking deeper
  36. questions related to the semantics.
  37.  
  38. Are you not aware that the innermost nested function will be called first, thus
  39. you will be matching the '*' token before the outermost '/'? In C (and other
  40. languages similar to C), the arguments of a function must be evaluated before
  41. that function is called.
  42.  
  43. In writing a predictive parser, what you typically want is recursion, not
  44. nested function calls! Else reverse the order, so that the slash is matched in
  45. the innermost call.
  46.  
  47. By the way, it's not good practice to omit writing explict types in your
  48. function declaration/definition.
  49.  
  50. >follow(expect,ifyes,ifno)
  51.  
  52. Is there a specific reason why you can't use an ANSI prototype?
  53.  
  54. Do you realize that your function is not even proper *old style* C? You have
  55. not declared expect, ifyes and ifno to have a type.
  56.  
  57. >Questions:
  58. >(1)    am I right in the expected problem?
  59. >(2)    how can this problem be evaded
  60.  
  61. Write a state machine that looks for comments. Comments can be parsed by a
  62. regular grammar---you don't need an LL(1) predictive parser to look for
  63. comments. A state machine, based on a regular expression that swallows comments
  64. is sufficient.  You don't need a push-down automaton, just an FSM.
  65.  
  66. >(3)    is there an C++ equivalent of this function (without the problem)
  67.  
  68. Learn C first, then C++. ;)
  69. -- 
  70.  
  71.